Summary

Surface the full accepted credential set on /status as sdkKeys[] / mobileKeys[] arrays — each entry carrying the obscured value, the optional wire identifier, and an optional Unix-millisecond expiry. The existing scalar sdkKey / mobileKey fields are preserved and now designate which array entry is the anchor / primary.

expiringSdkKey is now computed deterministically from the accepted set: the previous code overwrote on each loop iteration (arbitrary with multiple expiring keys); it now reports the soonest-expiring non-anchor key, with a (expiry, value) tie-break.

Jira: SDK-2534

Background

The concurrent-keys epic (SDK-2453) lets an environment accept multiple SDK keys and mobile keys at once. Per the backend tech spec and RAC payload spec, the sdkKeys / mobileKeys arrays are the authoritative full accepted set, including the default/anchor key (also duplicated on the legacy scalar fields). The status endpoint mirrors that: the arrays carry every accepted key; the scalars designate the anchor / primary.

The wire format carries a non-secret key identifier alongside each credential's value (threaded through the model in #729 and exposed via AcceptedKeys() in #730). The identifier is genuinely optional — manual configuration and old-format (pre-concurrent-keys) payloads carry none — so it is modeled as a pointer and omitted from the JSON when absent.

Response schema

EnvironmentStatusRep gains two arrays plus a KeyStatus element type. The scalar fields are unchanged.

// KeyStatus is one accepted credential in the sdkKeys[] / mobileKeys[] arrays.
type KeyStatus struct {
    Key    string `json:"key,omitempty"`    // non-secret identifier; omitted when the source carried none
    Value  string `json:"value"`            // obscured credential secret
    Expiry *int64 `json:"expiry,omitempty"` // Unix-millis expiry; omitted for permanent keys
}

type EnvironmentStatusRep struct {
    SDKKey           string               `json:"sdkKey"`                   // obscured ANCHOR (designates which sdkKeys entry is the anchor)
    SDKKeys          []KeyStatus          `json:"sdkKeys"`                  // full server-key set, incl. anchor; always present, always ≥1
    EnvID            string               `json:"envId,omitempty"`
    EnvKey           string               `json:"envKey,omitempty"`
    EnvName          string               `json:"envName,omitempty"`
    ProjKey          string               `json:"projKey,omitempty"`
    ProjName         string               `json:"projName,omitempty"`
    MobileKey        string               `json:"mobileKey,omitempty"`      // obscured PRIMARY mobile key
    MobileKeys       []KeyStatus          `json:"mobileKeys"`               // full mobile-key set, incl. primary; always present, may be empty
    ExpiringSDKKey   string               `json:"expiringSdkKey,omitempty"` // soonest-expiring non-anchor SDK key (deterministic)
    Status           string               `json:"status"`
    ConnectionStatus ConnectionStatusRep  `json:"connectionStatus"`
    DataStoreStatus  DataStoreStatusRep   `json:"dataStoreStatus"`
    BigSegmentStatus *BigSegmentStatusRep `json:"bigSegmentStatus,omitempty"`
}

Array entry order is unspecified. The arrays are always present (never null): sdkKeys always contains at least the anchor; mobileKeys is empty for an environment with no mobile key (e.g. server-side only).

Example (environment mid-rotation: an extra service key + an expiring key)

"environment1": {
  "sdkKey": "sdk-********-****-****-****-*******00001",
  "sdkKeys": [
    { "key": "default",   "value": "sdk-********-****-****-****-*******00001" },
    { "key": "service-a", "value": "sdk-********-****-****-****-*******00002" },
    { "key": "old-key",   "value": "sdk-********-****-****-****-*******00003", "expiry": 1735689600000 }
  ],
  "mobileKey": "mob-********-****-****-****-*******00009",
  "mobileKeys": [
    { "key": "default-mobile", "value": "mob-********-****-****-****-*******00009" }
  ],
  "expiringSdkKey": "sdk-********-****-****-****-*******00003",
  "status": "connected",
  "connectionStatus": { "state": "VALID", "stateSince": 10000000 },
  "dataStoreStatus":  { "state": "VALID", "stateSince": 10000000 }
}

Changes

• Add KeyStatus and the sdkKeys[] / mobileKeys[] fields to EnvironmentStatusRep.
• The handler takes a single consistent GetAcceptedKeys() snapshot and drives every credential field from it — the scalar anchor/primary designations, the arrays (one per Server / Mobile group, always present), and expiringSdkKey. Because the anchor designation comes from the same snapshot as the key set, the two can't drift under a concurrent reconcile (previously the anchor was read separately).
• expiringSdkKey is the soonest-expiring non-anchor SDK key via slices.MinFunc, comparing (expiry, value) so the pick is deterministic on a tie.